编程的价值

直到最近与同事讨论问题时，我才意识到早年编程教育与实践的价值。

我们这几天在设计另一个管理沙盘，来模拟多只团队配合，共同完成一个大项目的情况，想测试一下大家如何更好的结网协作。我们以一个实际的案例为背景，开始做设计。

讨论设计的过程中，我发现一个同事不断陷入困惑 —— 经常在逻辑设计时陷入实现的细节，在讨论设计时又经常想到测试问题，这种困惑让沙盘设计止步不前。作为这个项目的合作者，我很快就发现了这个问题，在白板上画了如下示意图。

这张图说明了一个典型的项目该如何设计：从上往下看分为三个层次，概念层、逻辑层和细节层；从左往右分为两个阶段，左边是设计，右边是测试验证。

对于任何有软件设计经验的人而言，这是最粗糙和普通的「瀑布模型」，概括了软件项目的研发流程。根据这个流程，我们需要从左往右，从上往下的思考问题。

比如具体到设计这个项目时，我们首先来做「概念设计」。即探讨这个项目的本质是什么，争取用一句话来概括。

明确本质之后，往下一层做逻辑设计。在逻辑设计时，有两种典型的方法，第一种是明确「数据结构和流程」，第二种是类似面向对象的方法，首先明确有多少种「对象」，每种对象各有什么属性和操作，对象之间有哪些典型的「关系」。无论用哪种方法，都可以。

在做这一层时，需要注意两点，首先明确逻辑设计的确能围绕上层的概念设计展开，即能体现出问题的本质。其次，不要在这一层想具体实现的细节。很多人在做第二层次的逻辑设计时，总是和下一层次的细节设计混为一谈。这就仿佛在做算法设计时，总是想着具体编码时用什么样的函数实现 —— 这是不对的。逻辑设计一般而言是独立于具体实现的。需要解决的逻辑问题，在这一层次就可以解决，不要下探到细节设计中。这会让局面更加混乱。

在逻辑设计OK之后，再去考虑细节设计，也就是具体的流程。在软件项目中，这部分工作是编码。在IT行业，有大量的工程师只在编码层工作，他们不负责概念和逻辑设计，而是按照别人的设计文档实现具体代码，很多软件工程师自嘲为「码农」，但真正意义上的码农就是这种只干编码工作的人 —— 大约在1997年我们上算法课时，一个年轻老师就告诉我们，做算法设计的人待遇要比做编码的人高很多倍 —— 这个观点，我到后来工作时才体会到。

验证同样也是分层次的，我们也要分别完成概念验证，逻辑验证和具体测试。很多人过多的关注于具体实现，所以在验证时也只是做具体测试，忽视了概念验证和逻辑验证。这会带来一个结果，即项目看起来完成了，但是没有达到初衷。

虽然我在编程方面没有什么建树，毕业做了三年软件设计之后就离开了编程的一线工作，后来偶尔用Python写一些脚本处理问题，但计算机教育与编程实践却深刻改变了我思考问题的模式。

最近在与同事们讨论问题时，才发现我视之为「常识」的东西对大家而言并非如此，但这些内容不过是计算机教育中基本概念。回想当年的编程岁月，发现最重要的并非学会C或者Python编程语言，而是训练了一套严谨的问题探索和解决思路。

举一个例子，微软当年出版了很多编程流程、思想的书籍，其中一本中介绍了「如何解决软件bug」的思路给我留下深刻印象。作者在发现一个软件bug时，不会简单的就事论事，而是在解决完这个问题之后，问自己如下三个问题：

第一，还有没有同类型的问题未被发现？

第二，如何防止同类型问题再次发生？

第三，如何设计一种自动检查的机制快速发现同类型问题？

如此一来，解决任何一个简单问题，就顺带解决了一类问题，而且能设计出自动检测甚至防止再次发生的机制，真是一劳永逸！

这只是一个简单的例子，类似的编程思想还有很多，比如算法设计策略中的分而治之，空间换时间，测试驱动编程，二分法查找，广度优先，深度优先等等，这些都潜移默化变成我的解决问题之道。

现在看起来，真要感谢当年的编程教育 —— 它实实在在训练了我的解决问题能力，难怪现在有越来越多的有识之士提倡在孩子基础教育时就加入编程的训练。

我也提倡辉友们在有机会的情况下能学习一门编程语言（比如Python），学会用编程的方式解决问题。学习一门编程语言的难度要远小于学习一门外语，但其收益却不小于学会一门外语。

BTW，说到学习，找到同行者很重要，下面分享知识星球上一个辉友在周六发出的感慨。如果你爱好学习，知识星球会给你想要的氛围。

---

参考文章：怎样拥有完美的一生？

前一篇文章：相信指数的力量

62/365

来知识星球，共同学习。

即刻加入，请点击阅读原文。